1. Field of Invention
The present disclosure relates generally to damage assessment and reporting in vehicles and other structures.
2. Background
For some structures, damage assessment may occur at a location that is removed from engineering resources (e.g., engineering personnel, test equipment, analytical tools, etc.). In order to determine the best course of action based on the damage, multiple back-and-forth communications between on-site personnel and off-site engineering resources may be needed.
One example of a situation in which damage assessment may be difficult is the assessment of damage to vehicles, such as military aircraft. A maintainer, located at the site of the damaged vehicle, may assess the damage and communicate the assessment to a remote engineering authority for analysis and disposition. The engineering authority may respond to the communication with a request for additional information. This process may be repeated a number of times before a final determination is made. As a result, there may be a significant delay in the vehicle's return to service.
There may be further delay as the disposition (e.g., repair strategy, procedures, structure usage restrictions, etc.) is approved and communicated to the maintainer. Additionally, the methods used to convey damage and disposition information (e.g., telephone, email, etc.) are vulnerable to human error. Errors may further increase the delay in returning the vehicle to service, and may increase the repair cost.
Additionally, damage information may not be retained in a meaningful way in existing damage assessment and reporting schemes. For example, communications between a maintainer and an engineering authority may consist of an email exchange, which may be printed out and put into the vehicle's file, or which may be maintained on a server. The damage and analysis information, both current and historical, may be difficult to obtain and interpret. As a result, similar damage events may not be efficiently assessed and analyzed, which may increase the average time a vehicle is unavailable for use.
In some industries, automated failure diagnosis may be accomplished in different ways. For example, in the automobile industry, on-board computers may be used to monitor operating parameters. In response to an out-of-bound operating parameter, an error code may be generated.
For example, an automobile may include an oxygen sensor to monitor the amount of oxygen in the exhaust, so that the air/fuel mixture may be adjusted to reduce emissions. An on-board computer may detect parameters indicative of the oxygen sensor performance. When the parameters indicate that the oxygen sensor should be replaced, an appropriate error code may be generated, and a “check engine” or other warning light may be turned on. A maintainer may read the error code, determine that a faulty oxygen sensor is indicated, and replace the oxygen sensor.
Although automated failure diagnosis may provide a number of benefits, it may not be optimal for some systems. For example, in systems where there may be a large number of damage scenarios that are not easily automatically characterized a priori, implementing automated failure diagnosis may be impractical.